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Abstract 

One of the key elements to successful 
project management is the establishment of the 
"right set of requirements", requirements that 
reflect the true customer needs and are 
consistent with the strategic goals and 
objectives of the participating organizations. A 
viable set of requirements implies that each 
individual requirement is a necessary element 
in satisfying the stated goals and that the entire 
set of requirements, taken as a whole, is 
sufficient to satisfy the stated goals. 
Unfortunately, it is the author’s experience that 
during project formulation phases 1 many of the 
Systems Engineering customers do not conduct 
a rigorous analysis of the goals and objectives 
that drive the system requirements. As a result, 
the Systems Engineer is often provided with 
requirements that are vague, incomplete, and 
internally inconsistent. To complicate matters, 
most systems development methodologies 
assume that the customer provides 
unambiguous, comprehensive and concise 
requirements. 

This paper describes the specific steps 
of a Goals Analysis process applied by Systems 
Engineers at the NASA Langley Research 
Center during the formulation of requirements 
for research projects. The objective of Goals 
Analysis is to identify and explore all of the 
influencing factors that ultimately drive the 
system's requirements. 


1 NPG-7 120.5 Program and Project Management Process and 

Requirements , rev A, NASA, April 1998, p 18. 


Introduction 

Goals analysis is predicated on the fact 
that no project operates in a vacuum; there are 
interfaces between the customer, the builder, 
and the environment, 2 or the rest of the world 
(figure 1). The participating organizations at 
each of these interfaces represent potential 
sources of goals and objectives that may 
influence the requirements of the system under 
development. 


Figure 1. The Environment today 2 



The author believes the concept of 
Goals Analysis is analogous to the concept of 
Requirements Analysis. Where the latter 
establishes a trade space, or region of feasible 


2 Blanchard, B. S., Systems Engineering Management . 3rd ed., Wiley- 
Interscience, 1991, figure 1.1, p 2. 
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Figure 2. Trade Space - Region of 
Feasible Solutions 3 



solution (figure 2), 3 the author suggests that the 
former establishes an influence space (figure 
3), 4 or region of overlapping interests. It is the 
author’s belief that the source of all 
requirements driving the system's design are 
captured within the goals and objectives that 
define the boundaries of a fully developed 
influence space. 

It is also the author’s belief that 
rigorous application of Goals Analysis, to seek 
out and explore all the interfaces and associated 
influence factors, will lead to better and more 
rapid requirements development and the 
minimization of requirements creep. 

Why is Goals Analysis Needed? 

It is the Systems Engineer's task to 
bring structure, in the form of a systems 
solution, to an inherently ill-structured and 


3 Eppen, Gould, and Schmidt, Introduction to Management Science . 
4th ed., Prentice-Hall, 1993, figure 3.7, p 102. 

4 Motley, Albert, Goals Analysis Process , an internal document of the 

Systems Engineering and Controls Branch, NASA, May 1999. 


unbound world of human needs. 5 Most 
literature on the subject of Systems 
Engineering methodology illustrates the 
Systems Analysis and Development process as 
some form of flow diagram where the customer 
needs or requirements are an input to the 
process. While the process may contains steps 
to validate the customer inputs, seldom does 
the process include explicit steps to assist the 
Systems Engineer in developing and refining 
these inputs. 


Figure 3. Influence Space: Region 
of Overlapping Interests. 4 



There is literature, such as that by 
Rechiten, 6 which provides useful Goals 
Analysis techniques. These techniques 
encourage the Systems Engineer to work with 
the customer to progress from problem 
statement to systems solution. Included are 
such processes as working the problem 
statement forwards, from problem to solution, 
and then working it backwards, from solution 
to problem. Another approach is to generalize 

5 Rechtin, Eberhardt, Systems Architecting - Creating & Building 
Complex Systems . Prentice-Hall. 1991, p 1. 

6 ibid., p 54. 
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the problem statement then attempt to focus on 
specific problem solutions. A third technique 
is to explore multiple parallel problem 
solutions based on partial evidence of a 
solution's viability. A final suggestion is the 
use of analogies and metaphors to relate the 
current problem with previous system 
solutions. However, Rechiten is quick to point 
out that these techniques must be used with 
careful judgment and that they are best applied 
in cases where just "...a few leaps of 
imagination may bring the problem and 
solution together." 6 The author has found that 
techniques of this nature are generally not very 
useful when working with new, large, and 
complex problems. 


Figure 4. Bomen Spiral Diagram 7 



Bohem's spiral model, 7 (figure 4) is 
perhaps one of the most frequently referenced 
illustration of the structured systems process. 
However, this model also assumes the 


7 Boehm, B.W. "A Spiral Model of Software Development," Software 

Engineering Project Management . IEEE Computer Society Press, 1988, 

pp 128-142. 


requirements are given by the customer and not 
a product of the process. While the model's 
formulation steps include "determining the 
system objectives and constraints." 7 The 
author agrees with statements by Forsburg and 
Mooz that the specific role of systems 
engineering, and particularly the steps of a 
goals analysis process, in this model are 
obscured. 8 

Again, in the "Requirements 
Interrelationships and Supporting Data" 
diagram by Grady, 9 (figure 5) the customer's 
needs are illustrated simply as an input box to 
the diagram. No part of the process provides a 
structure for developing the needs. 


Figure 5. Requirements 
Interrelationships and Supporting Data 9 



During the Systems Definition phase of 
the "Integrated Waterfall Model" 10 (figure 6), 
Sage assumes that the group developing 
systems requirements are "...sufficiently 
informed about the intended purpose of the new 
or modified system such that they can identify 


8 K. Forsberg, and H. Mooz, "The Relationship of Systems 
Engineering to the Project Cycle," Proceedings of the First Annual 
Symposium of NCOSE . 1991, exhibit 4, p 58. 

9 Gradey, Jeffrey O., Systems Requirements Analysis . McGraw-Hill 
1993, figure 4.2, p 1 13. 

10 Sage, Andrew P., Systems Engineering . Wile Interscience, 1992, 
figure 1.6, p 17. 
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Figure 6. Integrated Waterfall Model 10 



and develop the system level requirements in 
sufficiently complete detail..." 11 Again, no 
structured process or methodology is provided 
to assist in the development and definition of a 
Customer's needs into a set of system goals. 

Finally, in Blanchard's "Software Life 
Cycle" model, 12 (figure 7) the entry block is 
titled "Identification of the Need" with an 
associated statement in the text that reads "this 
information is generally included in a software 
requirements specification." 13 This portion of 
the text does include a reference to Functional 
Analysis from a previous section in the book, 
but that topic deals primarily with the 
translation of systems requirement into detailed 
design criteria. The very next block on the 
diagram jumps directly into "Systems 

Conceptual Design" with no provision or 
mention of Goals Analysis. 

The lack of readily available 

methodology, or specific process steps, to 
perform goals analysis is not a criticism of the 
work published by the authors referenced in 
this paper but rather an observation by this 
author of the need to push Systems Engineering 
methodology further back into the lifecycle 

1 1 Sage, Andrew P., Systems Engineering . Wile Interscience, 1992, 
figure 2.3, p 49. 

12 Blanchard, B. S., Systems Engineering Management . 3rd ed., 

Wiley- Interscience, 1991, figure 3.25, p 121. 

13 ibid., p 121. 


process to the very first inception of a system's 
need by the Customer. 


Figure 7. Blanchard Software Life Cycle 12 



Figvr* 3J5. Software life cycle. 
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Goals Analysis Process. 

Typically, at the inception of a new 
project, the customer has already identified a 
set of top level goals that he/she believes are 
necessary to fulfill a perceived needs. The 
engineering group accepts these goals, then 
develops a system concept to fulfill the needs. 

Paramount to the success of any 
undertaking is the clear and coherent statement 
of what is to be accomplished. Without a 
concise statement of the goals, there is very 


4 





little chance of establishing direct linkage 
between the customer’s needs and the system 
designed to satisfying those needs. Unless this 
linkage is clearly established then it is all too 
easy to "... make an error of the third kind - 
solving the wrong problem ." 14 

The Goals analysis process outlined in 
the remainder of this paper is designed to help 
the customer fully explore all the factors that 
influence the perceived system's need and to 
articulate the most general top-level goals and 
objectives. The process also helps the 
engineering group understand the influencing 
factors driving the goals, which ultimately flow 
down to a quantifiable set of performance 
requirements for the system to be developed. 

As the architecture of the systems 
concept is refined and detailed, subsequent 
iterations of the Goals Analysis Process allows 
for development of lower and lower levels of 
system requirements, which tie directly to 
project upper level goals. 

Participants in the Goals Analysis 
Process 

The following people, or organizations, 
should participate in the Goals Analysis 
Process: the Program or Project Manager, the 
Lead Systems Engineer, the Systems 
Engineering Support Team, representatives 
from the Customer, representatives from the 
User group, representatives from Engineering 
Management, and representatives from each of 
the identified Partners. 

Identification of Partners. 

The first step in establishing the 
boundaries of the Influence Space is the 
identification of partners. For the purpose of 
this paper, a partner refers to any individual or 
organization that is participating in the project 


14 Rechdn. Eberhardt. Systems Architecting - Creating & Buildin g 
complex Systems . Prentice-Hall, 1991, p 53. 


or has an interest in the project's final results. 
The relationship between the project and the 
partner can generally be classified into three 
categories: Vested Interest Partners, 

Contributing Partners, and Influential 
Independent Partners. 

Vested Interest Partners are those 
individuals or organizations who have a 
strategic stake in the project. In other words, 
the strategies they have incorporated into future 
plans are dependent on, or affected by, the 
success of the project. Vested Interest Partners 
are generally the source of objectives that must 
be accomplished by the systems under 
consideration. 

Contributing Partners are those 
individuals or organizations who are involved 
with the project but only from a current 
business perspective. In other words, the 
success or failure of the project does not affect 
the strategies of their future plans (aside from 
the failure of any given business venture 
affecting an organizations future plans). 
Contributing Partners are generally the source 
of constraints that limit the bounds of viable 
solutions for the system under consideration. 

Influential Independent Partners are 
those individuals or organizations that have the 
ability of affect the project, but they are not 
involved from a current business perspective or 
from a strategic future perspective (partners of 
this type are often known as political friends or 
foes). Advocacy from Influential Independents 
may come at a price; that price often takes the 
form of additional objectives for the system to 
accomplish. Opposition from Influential 
Independents often takes the form of additional 
constraints that further limit the bounds of 
viable solutions for the system under 
consideration 

It is quite possible that any given 
partner may fall into more that one 
classification. This is not a problem as the 
classifications are actually just constructs to 
assist the customer in exploring and identifying 
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potential partners in a way that may not have 
been readily apparent. 

A technique for helping the customer 
identify partners is to ask questions such as: 

• "Who does the Customer want to know 
about this project?” 

• “Who does the Customer want to 
participate in this project?" 

• “Who might want to know about what the 
Customer is doing?” 

• "Who will the project, or the final results, 
affect?" 

The process of identifying Activity 
Partners should result in a listing of individuals 
and organizations that may/will/should be 
involved with the planning, development, 
implementation, and operations of the system 
under consideration. 

Establish the Metrics for Ranking the 
Partners 

Once the Partners have been identified 
they must be sorted in relative priority or 
significance of the partner to the project. Such 
a sorting requires a set of metrics for ranking 
each partner. The significance of each metric 
must be in terms of value to the customer or 
influence over the project. Several different 
criteria may be used in sorting the partner list. 
For example, one sorting may be by funding 
source. In other words, the most likely or the 
largest funding partner would be ranked higher 
on the list. A second sorting order may be by 
technical expertise. In other words, the 
partners with the critical technical capabilities 
or skills would be ranked higher on the list. 
Another possibility is to sort the partners by 
political advocacy. In other words, the most 
influential political advocates or foes would be 
ranked higher on the list. 

Generally, a project can identify several 
different metrics for sorting the partner list, 


each offering a new insight as to the relative 
value of each partner to the project. 

Outputs: Weighted listing and 

description of each metric to be used. 

Ranking Each Partner’s Relative 
Importance to the Project 

In this step, the list of Activity Partners 
is sorted in accordance with the metrics just 
developed. The reason for ranking partners at 
this stage of the analysis is often difficult to 
understand, but doing so now will prove 
invaluable during subsequent steps when 
resolving priority issues between partners 
becomes important. At this point it may be 
convenient (for future requirements tracking 
and flow down purposes) to assign unique 
identification numbers or letters to each 
partner. 

Outputs: Partner list ranked according 
to the metrics. 

Document the Current Situation 

This is the process of establishing and 
documenting the status quo. It is important to 
seek out and solicit support from those 
individuals most experienced in the technical 
fields related to the project. Research, to 
establish a complete understanding of the 
current situation's status and how it evolved, is 
the key to this step. Benefits of this step 
include a deeper understanding of the problem 
and lessening the possibility of duplicating 
previous efforts. 

The narrative of this Current Situation 
Document should delineate both the positive 
and the negative aspects of the status quo . 15 
Developing this narrative is best accomplished 
through group interaction with representatives 
from all project Partners. 

Outputs: Current Situation Document. 


15 Walters, J. Milam, ESSM Goals Analysis Effort , an internal 
document of the Systems Engineering Office, NASA, April 1991, p 1. 
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Develop the Issue Base 

The purpose of this step is to identify 
the issues of each Partner in reference to the 
system under consideration. These issues 
become the basis for each of the systems goals 
or subgoals. A good place to start is by 
exploring the Strategic Plans of each Partner. 
The Systems Engineer must work with each of 
the Partners to identify supporting and 
conflicting elements within their plan relative 
to the system under consideration. It is helpful 
to ask questions such as "How will the system 
under consideration support or hinder the 
Partner's future activities?" Each issue should 
be assigned a unique identification number or 
letter that is a composite of the originating 
Partner's identification. This will be important 
for future requirements tracking and flow down 
purposes. 

Avoid the use of compound statements. 
Try to decompose the issues such that each 
statement relates to a single issue and each 
issue is contained in a single statement. 
Decomposing the issues into basic statements 
will simplify the latter process of consolidating 
redundant issues and converting issues into 
Goals Statements. 

Outputs: Summary report describing the 
issues each partner has with the system under 
consideration. 

Consolidation of the Issue Base into 
the System’s Issue Table (the ’’Super 
Set" of Issues) 

The objective of this step is to 
consolidate the common or shared issues so 
that each issue is listed only once. Often, the 
issues of different partners will partially or 
fully overlap. If all the issues were represented 
in graphical form, the results would be a large 
and complex Venn diagram. 

If the contents of the Issue Base have 
been properly developed into basic statements, 
then consolidation is almost a clerical level task 
that can be accomplished by a single 


individual. However, if the issues have been 
expressed as compound statements, then 
consolidation will be a very difficult task that 
requires the entire team to accomplish. 

A useful technique is to generate a table 
of issues (similar to the "what" axis of a QFD 
Correlation Matrix ). 16 Be sure to include a 
column for mapping issues back to each and 
every partner sharing that issue. Also, each 
issue listed in the table must be uniquely 
identified. When two or more partners share 
the same issue, it is often convenient to adopt 
the issue identification of the highest ranked 
partner. This helps reduce the "proliferation of 
identifiers" and helps to maintain tracking and 
flow down of the issues from the source 
partners. 

Outputs: A System’s Issue Table that 
lists each unique issue. 

Prioritize the Systems Issue Table 

This is perhaps the most difficult step in 
the Goals Analysis Process. The customer, in 
concert with the Partners, must agree to the 
priority order of the System's Issue Table. In 
general, the issues of higher ranked partners 
receive higher-ranking priority, but this is not 
always the case. The Systems Engineer should 
anticipate significant negotiation and 
compromise between the partners before an 
iteration of this step is completed 

Outputs: A prioritized System's Issue 

Table. 

Develop Preferred Future 

The Preferred Future describes the 
combined Partners' view of the system upon 
successful completion of the project. This view 
must include the interfaces and how they 
operate. It is frequently prefaced by a "Vision 
Statement," a description of the desired 
accomplishments in relation to other efforts. 


1 6 QFD Awareness Training . Quality Education and Training Center, 
Ford Motor Corporation, 1989, p 26 
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This provides a clear understanding of where 
the efforts are pointed and what can be 
expected upon completion of the project. This 
portion of the analysis can be very helpful in 
solidifying required constituencies. Minimally, 
the narrative should contain all the positive 
aspects described in the Current Situation as 
well as corrections to all the negative aspects . 17 
Ideally, development of this narrative will 
stimulate ideas that are strides beyond the 
current situation. Care should be taken to 
prevent description of an idealized future that is 
unrealistic from the expected cost and schedule 
constraints as well as to prevent over 
achievement of the actual needs. However, no 
plans should be discounted in the early 
iterations of Goals Analysis, since those that 
are overly optimistic will be removed through 
validation and in subsequent iterations. 

Outputs: Preferred Future Document. 

Generate Goals and Objectives 
Statements 

In this step the issues of the Systems 
Issue Table are translated into Goals 
Statements. Each issue is rewritten into an 
objective statement such that accomplishing 
that particular objective will resolve the issue. 
Again, try to avoid the use of compound 
statements. Try to keep each statement a single 
Goal and each Goal a single statement. 

All the Goals and Objectives generated 
directly from the System's Issue Table are 
known as the root set or the set of imposed 
System Goals and Objectives. All the Goals 
and Objectives generated later in the process, 
for the purpose of providing logical continuity 
in the formation of a Goals Tree, are known as 
derived Goals and Objectives. 

Possibly the most critical facet of any 
project is the correct and concise statement of 
the top-level goal(s). The exact wording of this 
objective is crucial and must be very carefully 


considered. Generalization of the top-level goal 
is designed to take the problem addressed by 
the system out of its narrow context and 
explore more general considerations. In other 
words, what is the real problem? The primary 
method of achieving this generalization is a 
rigorous questioning of the stated top-level 
goals. Typical considerations include: 

• Why is the goal stated this way? 

• Are there underlying goals not brought to 
light which affect the wording, i.e. politics, 
personal agendas, etc? 

• Is the stated goal truly the objective or a 
means of achieving some other objective? 

The purpose is to guard against a 
technically acceptable system that is infeasible 
for other reasons and to assure that the true 
objective is pursued. Included is 

consideration of those directly or indirectly 
affected by the project. This may be 
accomplished in part by listing the political 
advantages of meeting the goal as well as 
possible drawbacks of pursuing the goal. If 
opposition from the Partners, in particular from 
the Influential Independent Partners, appears 
unmanageable, then a modification of the goals 
may be in order. 

The most effective method of 
performing this step is an interactive group 
session. Brainstorming 19 20 and Brainwriting 21 
are good methodologies to follow. The main 
point is that all inputs are heard and considered. 


18 ibid., p 1. 

19 deBono, Edward, "Lateral Thinking - Creativity Step by Step, 
Harper & Row, 1970, p 149. 

20 Adams, James, Conceptual Blockbusting, 3rd ed, Addison-Wesley 
Publishing, 1986, pp 134 - 137. 


17 Walters, J. Milam, ESSM Goals Analysis Effort , an internal 
document of the Systems Engineering Office, NASA, April 1991, p 2. 


21 Wycoff, Joyce and Richardson, Tim, Transformation Thinking, 
Berkley Publishers Group, May 1995. 
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Outputs: Concise and understandable 
top-level Goal Statement(s) and "root set" of 
imposed System Goals and Objectives. 

Partner Value Considerations 

An area rarely considered in goal 
development is the values of concerned and 
affected Partners. This issue is included to 
amplify and articulate the underlying personal 
goals contained in the Goal Statements and 
Preferred Future Document. Paramount for 
consideration are the values of partners with 
decision authority over continuation of the 
project 22 . This should lead to a reiteration of 
the potential advocate/foe list and the 
reevaluation of the reasons for their 
support/opposition. The purpose of personal 
goals and values that are unrelated to accepted 
project goals should be removed in this step. 
The considerations are designed to resolve 
unstated, non-technical conflicts contained in 
the top level goal and vision statements for the 
project. 

Output: Conflict resolution of non- 
technical issues. 

Develop the Goals Tree 

In this step, the top-level goal 
developed in the previous step is decomposed 
and mapped into subgoals of narrower scope. 
Subgoals are objectives, which if 
accomplished, assist in satisfying the next 
higher level goal. Typically, the major 
subgoals of the project will become the top- 
level goal for project support organizations. 
For example, if a subgoal of the project is to 
maintain instrument temperature to within 5° 
K, this may become the top-level goal for the 
thermal-control organization. The expansion of 
goals may be terminated when a given subgoal 
is measurable. When a subgoal is capable of 
being indisputably judged as satisfied, that 


22 Walters, J. Milam, ESSM Goals Analysis Effort , an internal 
document of the Systems Engineering Office, NASA, April 1991, p 2. 


branch of the hierarchy requires no more 
definition or decomposition. 23 

Individual subgoals are arranged into a 
hierarchical representation. This is easily 
accomplished by writing each goal statement 
generated from the Systems Issue Table on a 
card and arranging them so that each lower 
level assists in the accomplishment of the next 
higher level. As the development progresses, 
the lowest level goals are expanded further by 
discussion with the cognizant organizations. 
When gaps occur in the diagram, where 
imposed goals (or goals generated from the 
Systems Issue Table) are insufficient to provide 
a logical flow between levels, then derived 
goals (or goal statements generated during the 
analysis process strictly for the purpose of 
maintaining logical continuity) must be 
synthesized and inserted. Progressing in this 
manner assures that every objective by project 
personnel, even on the lowest level, is directly 
tied to the project's top level goal. 

The result of this effort is a graphical 
hierarchical representation of the project goals, 
which contains technical and non-technical 
requirements at the terminating branches. The 
representation takes the approximate form of an 
organizational chart. One output of the effort is 
a set of technical requirements for the project. 
The tree may also provide information that 
affects non-technical requirements such as cost 
and schedule. 24 

Two useful tests on the structure of the 
Goals Tree are: 1) to ask if each individual goal 
on a given level is a necessary element to 
fulfilling the next higher level, and 2) if all the 
goals as a set on a given level are sufficient to 
fulfill the next higher level. Additional 
decomposition and expansion are required until 
the goals of each level can pass these two tests. 

Output: Goals Tree 


23 ibid., p 3. 

24 ibid. 
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Validate 

At this point, the process departs from 
earlier subjective considerations and becomes 
objective. 25 The outputs of previous steps are 
now scrutinized. Through editing, selection, 
comparison, etc., a validated version of the 
work to date is produced. Where criticism was 
previously discouraged, it is now invited. The 
purpose is to decide which facets of the work 
truly belong, which may be deleted, and which 
insures that a logical flow down has been 
developed. 

Output: Validated version of work to 

date 

Iterate the Process 

Much of the power of the systems 
approach comes from the idea of iteration by 
one-pass analysis. 26 This allows the individual 
steps to be performed at a general level during 
the early iterations, then defined in further 
detail during subsequent iterations. Also this 
enables incremental refinement of the output 
for each step as understanding of the entire 
system, gained through repeated iterations of 
the process, is continuously improved. 

Output: Improved Goals Analysis 

Conclusions 

This paper has described the specific 
steps of a Goals Analysis process applied by 
Systems Engineers at the NASA Langley 
Research Center. Projects that apply this 
process to the early phases of a research project 
will improve their understanding of factors 
influencing the project and perhaps lead to 
better requirement development with a reduced 
chance of requirement creep. The outputs of a 
Goals Analysis will provide excellent input for 
a Requirements Analysis process such as 


25 Walters, J. Milam, ESSM Goals Analysis Effort , an internal 
document of the Systems Engineering Office, NASA, April 1991, p 4. 

26 ibid. 


Quality Functional Deployment (QFD). 27 But 
that is a topic for another paper. 
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